Title: Zero-level Bazooka and Bazooka Befuddlement fixes
Author: Assassin
Version: Beta 0.20
Applies to: Secret of Evermore -- US version, Spanish, French, German, and English
            European versions
Tested on: US version, and less so on the Spanish, French, German, and English European
           versions

Contents:

        Bazooka-Two-U.ips  = the SoE (US) patch
        Bazooka-Two-EG.ips = the SoE (Europe - English and German) patch
        Bazooka-Two-F.ips  = the SoE (Europe - French) patch
        Bazooka-Two-S.ips  = the SoE (Europe - Spanish) patch

        Anti-Bazooka-Two-U.ips  = the SoE (US) anti-patch
        Anti-Bazooka-Two-EG.ips = the SoE (Europe - English and German) anti-patch
        Anti-Bazooka-Two-F.ips  = the SoE (Europe - French) anti-patch
        Anti-Bazooka-Two-S.ips  = the SoE (Europe - Spanish) anti-patch

        The "Anti-patches" effectively remove this patch.

        readme.txt = this file

        bank-8D-orig.txt = commented original Bank 8D/CD code (SoE US)
        bank-8E-orig.txt = commented original Bank 8E/CE code (SoE US)
        weapon-starting-levels-orig.txt = commented original Bank 8F/CF code (SoE US)

        bank-8D-fix.asm = commented fixed Bank 8D/CD code (SoE US).  Now as an assemblable
                          .asm file!  Also includes how the SoE European patches' offsets
                          differ from the SoE US version's.
        bank-8E-fix.asm = commented fixed Bank 8E/CE code (all versions).  Now as an
                          assemblable .asm file!
        weapon-starting-levels-fix.asm = commented fixed Bank 8F/CF code (SoE US).  Now as
                                         an assemblable .asm file!  Also includes how the
                                         SoE European patches' values differ from the
                                         SoE US version's.

ROM Addresses: All - CE/A49D thru CE/A4A0, CF/8057 thru CF/807D
               SoE US - CD/A521 thru CD/A524, CD/A7D7 thru CD/A7DA
               SoE European English, German, and Spanish - CD/A38E thru CD/A391,
                                                           CD/A5F0 thru CD/A5F3
               SoE French - CD/A36D thru CD/A370, CD/A5CF thru CD/A5D2
  (NOTE: The game actually runs the Bank Cn code in Bank 8n.)

Functions added (existing code areas - All): CF/8068 - 22 bytes
Functions added (free space): None
Additional Square functions used: None

Urgency: Medium.  There are two bugs here.  One is just display-related, albeit with three
         instances.  The other can increase difficulty a little.  How relevant it is depends
         on how much you choose to control the Dog after getting the Bazooka, or how much
         you use Energize with that weapon (as the spell gives more bang for the buck with
         conventional weapons).

============================================================================================

The latest versions of all my patches can be found at either of these sites:

http://www14.brinkster.com/assassin17/
http://home.comcast.net/~assassin17/

============================================================================================

TABLE OF CONTENTS

0. Description
1. About the Action Menu and Bug #1
2. More on Cause of Bug #2
3. What my Patch Does
4. PAR Code for Bug #1
5. Another Bazooka Bug
6. For Testers
7. FAQ
8. Revision History
9. Credits
Unnumbered: Copyright notice

____________________________________________________________________________________________

0. DESCRIPTION
____________________________________________________________________________________________

Two bugs involving the Bazooka here:

--------------------
At the start of the game, a Level of 1:0 is assigned to nearly all of the Boy's
weapons (including bare hands, which are never usable), and to the Dog's
attack.  However, the Bazooka is skipped, so it keeps its default level of 0:0.
This isn't a problem for normal, player-controlled use, but it does cause a
couple of issues:

1) When assigning a charge level to the non-player-controlled character on the
Action menu, you won't have any options above 0 for a Boy with the Bazooka.
This means that such a character could swing the Bazooka at nearby enemies,
rather than necessarily waiting for it to charge to 100%.
2) Energize won't work properly with the Bazooka.  Instead of filling to 100%,
the charge bar will cycle repeatedly or stay at 0%, the weapon won't be
fireable, and you won't be able to run with it.

--------------------

The Bazooka is different than other weapons in that it has subtypes: the three
varieties of ammunition it can fire (Thunder Ball, Particle Bomb, and
Cryo-Blast).  Many of the routines that load a pointer to weapon/ammunition
data take the subtype of the currently chosen shell into account.  However,
three do not, so they'll just use the first pointer under the Bazooka, which
indexes Thunder Ball's data.  These three cases are:

1) Displaying the existing weapon's Battle Power on the main weapon ring (the
Bazooka subring is fine).
2) and 3) Displaying the ammunition name and icon on the Stats menu.
--------------------

This patch fixes the first bug by setting the Bazooka to Level 1:0 at the start
of the game.  (If you're further along, you'll need a PAR code; see Section 4.)
It fixes the second bug by accounting for currently selected ammunition when
loading a weapon pointer in three instances.

____________________________________________________________________________________________

1. ABOUT THE ACTION MENU AND BUG #1
____________________________________________________________________________________________

A refresher on the four charge level options on the Action menu:

This screen works by reading your current weapon (or dog attack) level, and
graying and disabling any choices which exceed that number.  Since most of your
weapons start at Level 1, as does the dog's attack capability, you're almost
guaranteed that 0 and 1 will always be available in the Action screen.  The
selected levels work like this for computer-controlled characters:

0) They'll attack whenever the situation calls for it, without necessarily
   waiting to reach 100% first.  But they will go to 100% if there's nothing
   nearby to attack.
1) They'll wait until 100% before attacking, and won't charge beyond that.
2) They'll wait until level 2 (full thin red bar) before attacking, and won't 
   charge beyond that.
3) They'll wait until level 3 (full thick red bar) before attacking, and won't
   charge beyond that.

The bug means that only a choice of "0" is available for a Bazooka wielder, so
the computer-controlled character might use weak bludgeons on nearby enemies,
when you'd rather have him waiting and firing.  Worse yet, he might swing when
the enemy is in the line of fire, but well out of bludgeoning reach.

____________________________________________________________________________________________

2. MORE ON CAUSE OF BUG #2
____________________________________________________________________________________________

Each weapon has a unique index:

00 = Nothing

02 = Bone Crusher
04 = Gladiator Sword
06 = Crusader Sword
08 = Neutron Blade

0A = Spider's Claw
0C = Bronze Axe
0E = Knight Basher
10 = Atom Smasher

12 = Horn Spear
14 = Bronze Spear
16 = Lance
18 = Laser Lance

1A = Bazooka

------------

The game uses the index of the weapon currently held by the boy, stored in 7E/0ABA, to
address the table of weapon pointers, which starts at C4/3874.  It then accesses the
particular weapon's data block at C4/weapon_pointer.  This data block contains various
information on the weapon, including a pointer to its icon, and its Battle Power in the
first two bytes.

Notice there's only one bazooka index, which is appropriate given there's only one bazooka
(ok, you get two during the course of the game, but they're the same thing).  How, then,
does the game differentiate between Thunder Ball, Particle Bomb, and Cryo-Blast, each with
their unique battle powers and icons?  If the current weapon index is 1Ah, the game reads
the currently selected bazooka shell from 7E/2349:

0 = Thunder Ball
2 = Particle Bomb
4 = Cryo-Blast

Then, it loads a pointer to the ammunition's data block from C4/388E + shell_index (a.k.a. 
C4/3874 + 1A + shell_index).  Note that in the case of bazooka shots, the ammunition's
Battle Power _replaces_ the boy's Attack stat as opposed to adding to it as the other
weapons do.  Also, as you can see above, there's no data pointer or unique index for a
bazooka without ammunition.  Instead, you retain the index of whichever ammo you had
equipped, but if you're out of shells or you're not charged to 100%, the bazooka acts as a
bludgeon, and it's assigned a hard-coded Battle Power of 18 to be added to the boy's Attack
stat.

Now that you have the background, onto the bug's cause.  In some places, the game never
checks for a weapon index of 1Ah, nor performs the needed read of the current ammunition.
This means those sections of code will always retrieve the weapon data pointer from
C4/388E if you have the Bazooka.  This is the same as having an ammo index of zero, so
the game will always think you have Thunder Ball loaded in those cases.

These cases are:

1) Displaying your current weapon's Battle Power (i.e. the number to the left of the arrow)
   when on the Weapon Ring.  Note that you'll see the correct Battle Power when in the
   Bazooka subring, as the game does things properly there.

2) and 3) Displaying your current ammunition's name and icon on the STAT menu.

While there are three separate faulty sections of code, it's really the same bug repeated
three times.  I can only attribute the cause to oversight.  The Bazooka's use of dual
indices is unique compared to other weapons, which can access their data with only
a single index.

____________________________________________________________________________________________

3. WHAT MY PATCH DOES
____________________________________________________________________________________________

For Bug #1:

It sets the Bazooka to Level 1:0 at the start of the game, just as is already done for all
of the other weapons.  (If you're further along in your playthrough, you'll need a PAR code;
see Section 4.)

--------

For Bug #2:

It does just what Square already does most of the time.  If the index of the weapon
currently held is 1Ah (Bazooka), I proceed to retrieve the ammo type and get a pointer to
the current ammunition's data.  The process was described in more detail in Section 2, if
you're interested in the tables involved.

____________________________________________________________________________________________

4. PAR CODE FOR BUG #1
____________________________________________________________________________________________

The ROM fix for Bug #1 requires certain code to run at the start of a game.
What if you're past that point?  You might not want to start over just to reap
the benefit.  Fortunately, the Bazooka can be made Level 1:0 with a little RAM
tinkering.  Here are PAR codes:

7E0AF700
7E0AF801

The first line probably isn't necessary, as I believe that both $0AF7 and $0AF8
are zero before applying any code.  But it's there for completion.

The codes have been tested on all versions of the game.

____________________________________________________________________________________________

5. ANOTHER BAZOOKA BUG
____________________________________________________________________________________________

When you fire Particle Bombs or Cryo-Blasts from the Bazooka, the ammunition is never
actually consumed.  Hence an infinite supply.  That shouldn't happen.  Thunder Ball works
fine.

The cause is that a routine which sets up attacks will only check and decrement the
ammunition count if the attack type is Thunder Ball.

The European versions of SoE fixed things by expanding that test to also include Particle
Bomb and Cryo-Blast.  I followed Square's example in making my USA patch ("Infinite Bazooka
Ammo fix"), which is available on my websites.

This bug might seem similar in cause to Bug #2, but it's actually distinct.  With Bug #2,
the game forgets to check for ammunition subtype.  With the Infinite Ammo bug, the game IS
specifically checking for the ID of the Thunder Ball attack (or rather, the pointer to the
Boy's sprites that's present when Bazooka + Thunder Ball is equipped); it just fails to
check for the other two shells' IDs.

____________________________________________________________________________________________

6. FOR TESTERS
____________________________________________________________________________________________

Any testing is appreciated.  I tested both bugfixes on all versions of the game.  However,
Bug #1's fix was examined using an early-game save with the Bazooka and its shells hacked in
via PAR codes, as I don't feel like playing through the game from the start.  Same deal for
my evaluation of Bug #2 on the European releases, as I simply lack late-game saves for
those.  This method shouldn't be defective, but it'd be nice to hear the results of a "real"
playthrough as well.  Also, I have yet to test the Energize aspect of Bug #1 on non-American
versions, but don't see why it wouldn't work.

Please provide feedback on Slick Productions:
http://slickproductions.org/

or on Mnrogar's Den:
http://mnrogar.slickproductions.org/

or PM assassin17 on the GameFAQs message boards:
http://www.gamefaqs.com/

Thanks!

____________________________________________________________________________________________

7. FAQ
____________________________________________________________________________________________

Q: When you're out of ammo, why does the last ammunition you had loaded still appear in the
   STAT menu, and its Battle Power still appear when you're in the Weapon Ring?

A: I hear ya!  Frankly, I would have added a fourth ammunition type of "None" and given it
   its own data block.  Not doing this may've been another oversight on Square's part.
   More likely, they knew they just could get away with a check to change the attack
   performed by an empty Bazooka (as described in Section 2).  Thus, while showing ammo you
   don't have may be illogical, it won't have any meaningful impact on gameplay.

   At any rate, addressing the issue is currently beyond my ability.  I'd have to change a
   lot more code, introduce a new data block for the empty Bazooka, and create a new icon
   for it.  That would be challenging under any circumstance, but because I don't know where
   this game's free space blocks are, I really have no shot at it (no pun intended).


Q: Let's say I want to keep the Bazooka-wielding boy's Action level on 0, so he bludgeons at
   will, but I don't want him to stupidly swing at enemies who are out of range (as
   described in Section 1).  What can be done?

A: The solution to that is well beyond my skills.  It'd get more into the guts of the game's
   AI, which I know nothing about.  If there are weapon "striking ranges" kept in lookup 
   tables to determine where a Boy holding various weapons can reach, then likely, another
   entry in said tables would need to be added for an empty Bazooka.  And I suspect the new
   index needed for this would best be facilitated by doing what was also proposed in my
   prior answer: "[adding] a fourth ammunition type of 'None' and [giving] it its own data
   block".


Q: Who's to say that Square didn't want to stop Energize from working with the Bazooka,
   because the combination of the two would be too overpowered?

A: Energize actually gives more oomph to conventional weapons, taking most of the waiting
   away from charging to as much as a lofty Level 3.  Meanwhile, the Bazooka only goes up
   to a modest 100%, so its benefit from the alchemy, realized by this patch, is less
   pronounced.


Q: Two of the original commented assembly files use Bank CD and CE, while the other uses
   Bank 8F.  Yet per this Readme header, they're supposedly three consecutive banks.  What's
   up with that?

A: *Cue dancers*  I was being a flake, though neither approach is actually inaccurate.
   Bank Cn is where the full HiROM banks are loaded.  However, the top halves of Bank 8n
   mirror the top halves of these banks.  Square chooses to run this game in Bank 8n, as it
   lets them access RAM in the bottom eighth of a bank (e.g. character stats) and ROM in the
   top half of a bank (e.g. enemy stats), without changing the bank register.  So using
   Bank 8n for disassembly better matches game runtime, while picking Bank Cn is proper for 
   hex editing the ROM file, or assembling code to it.  As for why I was inconsistent?  I
   converted some Bank CF Functions to list "8F/", then decided I didn't feel like
   converting them back.


Q: So what's in the bottom half of the Cn banks in the ROM file?

A: Data, I presume.

____________________________________________________________________________________________

8. REVISION HISTORY
____________________________________________________________________________________________

Version 0.20 : May - early July 2005; November 19, 2007; November 25, 2010; December 27,
               2012; January 2-4, 7-8, 10-11, 15, 24, 26-29, 2013; February 4, 8-9, 11,
               2013; April 27, 2013; May 12, 2013; June 16, 2013; July 3-6, 2013:

  - May 1, 2005: In a GameFAQs thread about the Infinite Bazooka Ammo for Particle Bomb and
    Cryo-Blast bug, posted that I knew about Bug #2, as it was somewhat related.  Dunno when
    I discovered it, but likely mid-2004 to early 2005.
  - May 10: Wrote some of the Bug #2 Readme portions, and had a basic idea what my future
    patch would do.  WAAY future, it turns out.
  - May 20: Posted on GameFAQs about the Action screen variety of Bug #1.  Probably
    discovered within a couple months before that.
  - June 24: Copy+pasted starting weapon level assignment code.
  - July 4-5: I debate two ways to fix Bug #1, asking for input on GameFAQs and Mnrogar's
    forums.  The Kirby and AspiringSquire convince me to use the level-setting method for
    a fix, rather than putzing with the Action screen.
  - July 8: zeero grave posts Energize form of Bug #1 on GameFAQs.  I post a PAR code to
    fix both forms of Bug #1, as I somehow sensed a ROM patch wouldn't exactly be
    forthcoming.
  - 2+ years: A bunch of nothing.
  - November 19, 2007: Started work on Bug #1 fix's code.
  - 3 years: A whole bunch of nothing.
  - November 25, 2010: Made some changes to said code.  This must've tired me out, 
    because...
  - 2+ years: ...A Whole Bunch of Nothing is now a trilogy.
  - December 27, 2012: Commented the Bank 8F code that assigns starting weapon levels.
  - January 2-4, 2013: Worked on commenting that more and nearby functions.  Adjusted Fix #1
    code a little.  Found code relating to weapon ring and Stat menu for Bug #2.  Probably
    knew where it was in 2005, but failed to write it down.  Arrived at a working SoE US ROM
    file that fixes both bugs.  Made fixes' code into .asm files, with European version
    differences noted where needed.  Wrote bug descriptions for Readme.
  - January 7-8: Commented more code in various banks, worked on Readme.
  - January 10-11: Made .IPS patch and anti-patch files for SoE USA.  Worked a little more
    on Readme.
  - January 15, 24: Worked more on Readme.
  - January 26-29: Made European English, German, French, and Spanish patches and
    anti-patches.  Tested USA patch more, and tested some on all 4 European patches.  A
    little more Readme work.  Realized that Bug #1 with Energize will also prevent boy from
    running with Bazooka.  Added to Readme, and verified that patch fixes it.
  - February 4, 8-9, 11: Tested PAR code on clean European ROMs.  More Readme work.
  - 2.5+ months: You guessed it ... a smaller bunch of nothing. :P  Spending time on tax
    preparation (you wouldn't believe what a paper trail I can generate earning slightly
    below market returns), and on putting ass grooves in chairs.  While dwarfed by prior
    delays, this one is still shameful, given I had working patches ready.
  - April 27, May 12, June 16, and July 3-5: More Readme work, including preparing this
    Revision History and the Credits section, and more original code commenting.  I keep
    widening what I'm commenting.  Lots of it probably has no business being distributed
    with this patch, but it'll see the light of day in one form or another.  Paste the
    relevant parts (and some of their neighbors) from Bank disassembly files into the
    disassembly files distributed here.
  - July 6, 2013: Released patch.

____________________________________________________________________________________________

9. CREDITS
____________________________________________________________________________________________

  - zeero grave for discovering the Energize form of Bug #1.  Useful to know in and of
    itself, and underscored that the lack of a "1" choice on the Action screen was indeed a
    bug, since the two have a common cause.

  - The Kirby for feedback and reasoning in choosing a fix method for Bug #1.

  - AspiringSquire for feedback and reasoning in choosing a fix method for Bug #1.

  - Mnrogar for various feedback about Bug #1.  His whereabouts are unknown these days, but
    his excellent website and forums live on:  http://mnrogar.slickproductions.org/

  - Minako Aino, Crimson Hellfire, Swiftcrack14, and Telsa Dragon for replying in my
    GameFAQs topic.

  - byuu for making xkas v0.06, a fine 65816 assembler which has sped up the patchmaking
    process.  Visit his website:  http://byuu.org/

____________________________________________________________________________________________

Secret of Evermore copyright 1995 Squaresoft.
This readme and all other files in the archive (as listed above)
  copyright 2005, 2007, 2010, 2013 Assassin.
All rights reserved.
